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ABSTRACT 

Recognizing the need to balance generality and 
economy in system costs, the Project INFO team at Stanford University 
developing OASIS has sought to provide generalized and powerful 
computer support within the normal range of operating and analytical 
requirements associated with university administration. The specific 
design objectives of the OASIS system are: (1) responsiveness to 
information needs, current and projected, of ma jor university 
administrative offices; (2) support with both volume batch and 
teleprocessing requirements with reasonable efficiency from the same 
file; (3) fast terminal tesponse and simultaneous batch program 
activity; (4) minimal system overhead and a favorable 
cost/performance ratio; (5) hardware and software reliability 
features appropriate to the demands of an online environment. This 
document covers the executive control services, data base services, 
terminal services, and generalized services of the OASIS system. 
Appendixes include the OASIS file structure components, network 
design, development plans, and command and reserved words. 
(Author/PG) 
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OASIS has been developed by the staff of Project INFO with the 
assistance of other members o1 the Management Systems Office 
of Stanford University and major support from a grant by the 
Ford Foundation. 11 is available without charge to tax exempt 
educational institutions for their own non-profit purposes. 
Lfcense for o^her uses may be obtained. 

Detailed documentation on OASIS is contained in three volumes 
as shown below. An OASIS Newsletter is published quarterly and 
is available upon request. 

Volume I— OASIS User's Guide (lo be published in 1974) 
Volume U — OASIS Application Programmer's Guide 
Volume III— OASIS Syi>tem Mainlenance Guide 

g 1973 by the Board of Trustees of the Leiand Stanford Junior 
University. All rights reserved. 



Address all communications to Director, Project INFO, Encina 
"all, Room 30, Stanford, California 94305. 
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INTRODUCTION 



Syslem Objectives & Features. The development of computer 
technology has been characterized since its inception almost 
three decades ago by an exponentially decreasing cost of 
providing electronic machine performance balanced against 
an exponentially increasing range of requirements and com- 
plexity In computer systems. Historically, computer systems 
have been tailored to rather specialized functional require- 
ments which made the most efficient use of their potenNal. 
However, as the use of computers expanded within organiza- 
tions to embrace not only most major clerical functions but 
also a number of important management support functions, 
this fragmentation of systems has become a serious handicar>. 
Input and output format requirements are rigid and expensive 
to change, reports and analyses needing cross-functional 
gathering of Information generate excessive one-time pro- 
gramming requirements, and identical Items of Information 
become embedded In multiple machine-readable files. 

There have been a number of major generalized system 
development efforts carried on in recent years in an attempt 
to deal with the need for a unified approach to organiza- 
tional information processing requirements. The results of 
these efforts have frequently been mixed, either because of 
attempts to provide a breadth of system capability beyond the 
economic reach of the using organization, or because the 
system failed to address sufficiently current information sys- 
tem problems. Recognizing the need to balance generality 
and economy in system costs, the Project INFO team devel- 
oping OASIS has sought to provide generalized and powerful 
computer support within the normal range of operating and 
analytical requirements associated with university adminis- 
trative needs. 

The specific design objectives of the OASIS system are: 

■ Responsiveness to information needs, current and project- 
ed, of major university administrative offices. 

■ Support for both volume batch and teleprocessing require- 
ments with reasonable efficiency from the same file. 

■ Fast terminal response and simultaneous batch program 
activity, 

■ Minimal system overhead and a favorable cost/perfor- 
mance ratio. 

y .ware and software reliability features appropriate to 
v>nands of an online environment. 



■ Modular and flexible system design to meet changing re- 
quirements. 

■ Support for integration of data files and for consistent nam- 
ing and definition of data elements. 

■ Inclusion of features oriented to the non-technical user. 

These objectives have been realized in a data base manage- 
ment system with four logical components: Executive Control 
Routines, Terminal Services, File Services, and Generalized 
Services, Major features ol the system include: , 

■ Online multitasking within a single program partition, with 
each task protected from the activities of other tasks. 

■ A terminal command language which allows easy user 
access to all system features, 

■ Terminal communication facilities available to the applica- 
tion programmer that simplify the design and execution of 
online programs, 

■ A comprehensive set of services, including routines for 
defining, buil^fng, accessing, and restoring files. File access 
code is resident in the OASIS online partition and is reached 
by application programs via standard calling sequences. Ac- 
cess cal/s mc\u6Q retrieval, addition, and deleti6n services. 
Variable length record segments provide a significant degree 
of data compaction. All data may be referenced by nane via 
dictionary facilities, thus allowing the implementation of ex- 
tensive data security down to the data element level. 

■ Dynamic allocation of memory to online program modules 
and data buffers which conserves real memory and supports 
sharing of reentrant code where possible. 

■ A file enqueue dequeue facility which allows concurrently 
executing batch and online OASIS programs to access In- 
formation from the same files. 

■ An inquiry language, QUERY, which permits retrieval of 
selected file contents based on data element name specifica- 
tions and selection criteria, and supports the arithmetic op- 
erators plus, minus, multiply, divide, and the special functions 
COUNT, SUM, MIN, MAX, and AVG. An ORDERED option 
in QUERY provides an internal sorting capability to produce 
lists in ascending or descending sequence based on data 
element values. 

■ Multiple entry to file contents is possible through the spec- 
ification of varying levels of indexing of elements contained 
in the file. 
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■ An interactive Terminal Report Generator allows the com- 
position, specification, and testing of report programs which 
may be subsequently named, cataloged, and executed either 
online or in a batch mode. 

■ Support for online application programs written in ANS 
COBOL in modular format. 

Operating Environment. OASIS is designed for use on medium 
scale IBM 360/370 computers under control ot Ihe Disk Oper- 
ating System (DOS) and currently supports the attachment of 
Sanders 720 series CRT displays to the processor. (See Ap- 
pendfx for discussion of work now in progress to support 
OASIS under the full Operating System and with IBM 3270 
series CRT terminals.) Varying hardware configurations are 
possible, depending on the specific requirements of an instal- 
lation and the total load of OASIS and non-OASlS work to be 
performed. The machine configuration currently used in ihe 
Stanford Administrative Computmg Facility is shown above. 
The OASIS online system is operated eight hours a day at 
Stanford and occupies 150K bytes o1 memory during that time. 
Less would be required if fewer terminals were to be sup- 
ported. The minimum srze rn which several terminals could 
be driven using all OASIS services is approximately 100K 
bytes. During the evening operating period, OASIS files are 
available to batch programs in the same manner that standard 
IBM disk and tape files are attached to partitions and pro- 
grams. 

The relationship between DOS and OASIS is that OASiS ap- 
pears in all major respects just like a normal job step. Certain 
^'-'ifications have been made to DOS to allow OASIS to 
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maintain [ts integrity against inadvertent job cancellations 
and to enable inter-parlilion communications. These modifi- 
cations are self-contained and release-Independent. A tape 
drive for system logging messages is continuously attached 
to OASIS during both online and batch operations to provide 
restart and error recovery services. 

It is important to maintain the distinction between the 
OASIS system itself and applications which use it. OASIS fs 
written in IBM assembly language and its programs perform 
an array of services which, in the aggregate, comprise an 
online data base management system. Application designers 
may use this system to perform a broad variety of functions, 
depending upon specific needs of an adminlst'^ative office. 
For instance, a small and relatively static file of specialized 
information, such as a university space inventory, could be 
placed online primarily lo allow use of the generalized QUERY 
service to answer non-routine requests for data. On the other 
hand, a major student records application may require devel- 
opment of online data capture, file maintenance, and exten- 
sive printing of documents such as grade slips and transcripts, 
in addition to providing immediate online inquiry into the file 
to determine student directory information or academic per- 
formance status. In this case, application programs would be 
written in networks of 2K COBOL modules to handle the on- 
line requirements, and larger COBOL programs would be 
written to execute in batch partitions to support specialized 
printing and reporting needs. QUERY and the Terminal Report 
Generator would be used to deal with standard inquiry and 
reporting requirements. (See Appendix for discussion of on- 
line network programming.) 
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OASIS Executive ConlfOl. The OASIS Executive Conlfol Ser- 
vices perform a number of imporlani functions for the system/ 
including task scheduling, allocation of memory to tasks and 
f/0 buffers, and communicalions between partitions and the 
DOS Supervisor. These services are divided into three phys- 
ical sections of code, the first of which is resident within the 
DOS Supervisor and is called the permanent Exec. The second 
section controls the online partition and is called the fore- 
ground Exec. The third section is link edited into batch pro- 
grams whfch access OASIS files and is called the mini-Exec. 
The first two sections are required for ail terminal operations; 
the Ihfrd is needed only when OASIS batch programs are 
executing. The memory layout of OASIS under DOS is shown 
below. 



DOS Supervisor 
with Permanent OASIS Executive 




Batch Program Area 
(with mini-Exec for OASIS programs) 
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During system IP1_ procedures, the OASiS permanent EXs^c 
is inserted into the DOS Supervisor, requiring approximately 
2K bytes of memory. The principal function of this program 
IS to intercept and analyze all Supervisor Call (SVG) and pro- 
gram check interrupts. Most SVC requests are passed on to 
DOS; however, a number of them have been designed for use 
by OASIS and their processing is done within OASIS. The 
permanent Exec also performs initial processing before rout- 
ing program checks fo the appropriate DOS error routines. 

The foreground Exec is a collection of programs, most of 
which are continuously resident in main memory, that super- 
vise and coordinate the operation o< multiple user tasks. Each 
terminal is considered a task by OASIS and when active may 
be executing either user-written program modules, the OASIS 
Generalized Services, or code within the Exec Itself. Associ- 
ated with the foreground Exec Is a table of task information 
blocks called the task queue. Each of these blocks is associ- 
ated with one of the terminals and contains status information 
which is maintained by the task scheduler and used to deter- 
mine execution priorities, monitor errors, and allocate re- 
sources to tasks, OASIS is an l/O-driven time sharing system; 
once a task commences execution, it normally is allowed lo 
continue to execute until I/O Is requested or termination 
occurs, at which point the scheduler saves the current task 
status, requests the appropriate I/O from OOS if necessary, 
and branches to the task next in line for execution, OASIS is 
not a "swapping'' system and does not write to disk the 
modules being used by a task between active execution 
periods. 

The Exec also contains a polling routine to handle com- 
munications with the CRT terminals. The processor interval 
timer is set to a value which is dependent upon the total num- 
ber of terminals connected to the system. When the timer 
elapses and causes an interrupt, the polling routine takes con- 
trol and determines whether any terminal is seekmg to com- 
municate with OASIS. If a response is found lo the poll, the 
status of that task (s updated to request proce^^smg. Certain 
other status checking is also done at this lime and control 
is then returned to the active task at the point where the timer 
interrupt occurred. 

The foreground Exec operates in Supervisor state with a 
memory protect key of zero. This allows the setting of protect 



keys for all task modules operating In the online partition, and 
prevents an active lask from modifying information in modules 
of another task or in the system itself. 

As can be seen from the diagram on the previous page, a 
major portion of the online partit on is allocated to a pro- 
gram module area and a data page buffer area. The former is 
separated into 2048-byte blocks because this is the mirurnum 
area to which the protect key may be applied. The latter is 
divided into 1696-byte blocks to match the capacity of the 
disk storage devices. Allocation of module puges and data 
buffers to tasks is'handled d'mamically by the scheduler. 

When communications are needed from within a task pro- 
gram to an OASIS Exec service, those requests are made via 
a standard CALL statement of the form: CALL 'Service* [US- 
ING parami, param2, . . . paramN] where the parameters 
are dependent on the service called. There are three classes 
of service which may be accessed by a CALL statement: 

■ File Services requests — those activities related to disk and 
tape files. 

■ Terminal Services requests — those activities related to the 
terminals. 

« Control Services requests — all other activities (most ot 
these services are concerned with module linkages and back- 
up/restart activity). 

When a CALL is made from a task program, control is trans- 
ferred to the b'xec at the entry point of the particular service. 
{The service routine acts as an extension of the task,) For 
those S3rvices which include no terminal or file I/O activities, 
the above procedures are executed with no interruptions. 
For those services which do include I/O activity, however, the 
task is retired from active state while DOS processes the 
1^0 request. 

When the active task wishes to transfer control to another 
of its network modules, it issues a CALL request to indicate 
the name of the new module and the desired form of loading 
function. OASIS then loads and link edits the requested mod- 
ule from the OASIS loader file and transfers control to the 
entry point within that module. Four linkage services are 
provided: 

■ OLINK — a new copy of the module is loaded into one of the 
O module areas. 
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■ RLINK-— the module areas are searched for an unus6d copy 
of the module; a load occurs only if no old copy is available. 

■ LINKR — the module areas are searched for a copy of the 
module, even if it is in current use. 

■ OREPLACE — the new module Is loaded on top of the call- 
ing module. 

The OASIS Generalized Services use the LINKR linkage 
service in order to minimize memory utilization and load ex- 
ecution time. 

Command Language Processor. The Command Language 
Processor (CLP) associated with the OASIS Exec allows the 
user to communicate with the system. Through the use of key- 
words, he can call the Generalized Services, utilize the de- 
bugging facilities, load and execute his programs, perform 
system functions (such as LOGON, LOGOFF, and CLOCK), 
or send messages to the operator's console. The operator's 
console has additional privileged operations related to the 
status and condition of the system. 

The user communicates his requests via keyword com- 
mands or their optional abbreviations. {See Appendix for key- 
words and their meanings.) Certai i features of the CLP are 
standard for all requests: 

■ When ready for anottier user-specified command, the sys- 
tem will prompt ''COMMAND? " The user may respond with 
any of the CLP functions. 

■ An arrow (t) may be typed in as a user command at any 
time. The user will then be permitted to enter any command. 

■ If an error has been detected in a user command, the sys- 
tem will respond with '^RETRY" and an appropriate message. 

Each command must contain a keyword. Most commands 
also require one or more parameters. No special formatting 
is required and no command terminator is used. 

The time between user LOGON and LOGOFF is considered 
to be a session. To activate his terminal, the user types LOG- 
ON followed by his password. A successful request results in 
a display of the date, time of day, and message-for-the-day; 
the user may then enter further requests. When the user 
desires to terminate a session, he types in LOGOFF. The sys- 
tem responds with the length of his session and the terminal 



is returned to its inactive slate. When a temporary exit from 
a problem program occurs, a session break results. The user 
may enter any desired commands, then return control to the 
problem program by entering the command CONTINUE. An 
abnormal session break occurs when a problem program in- 
terrupt occurs. The system will respond '^PROGRAM CHECK 
INTERRUPTION" with the actual location, condition code, and 
type of error. 

Once the user has successfully performed LOGON, certain 
functions are always available. To find the date, time o1 day 
and current session duration, the user types CLOCK. He may 
send a message to the operator's console through the use of 
the MSG command. Certain other commands (QUERY, RE- 
PORT, DEFINE) may be input to the CLP and will resutt in the 
execution of Generalized Services programs. 

Problem programs are loaded from the OASIS loader file 
and put Into execution through use of the LOAD and EXE- 
CUTE commands, to which are appended program names. 
(The load and execute processes may be entered indepen- 
dently in order to facilitate debugging functions.) In r^^spor.se 
to such a request, the system loads the first module of the 
requested program into a 2048-byte area, of returns ap- 
propriate error messages if the program cannot be loaded. 
Execution of the program commences directly if an EXEC 
command was entered. Upon normal completion of pro- 
gram execution, the system will respond "NORMAL TASK 
TERMINATION". 

To facilitate terminal debugging of problem programs, the 
system provides special debugging commands, which are 
available only to specified terminals. As part of these capabil- 
ities, the terminal user may perform program tracing (TRACE 
and RESET commands) or specify and clear his own 'break 
points' by means of the BREAK and CLEAR commands. When 
a specified location is reached by the program, a session 
break resulls and control is transferred to the user. The pro- 
grammer can check the status of his program or attempt to 
correct a program check interruption through use of the 
SHOW and PATCH commands. If he prefers, he may have 
selected core location values printed out on the printer via 
the DUMP command for later reference. Displays and modifi- 
ra\\nn of hls user module areas, registers, and program status 
:n possible. 



The system also provides a set of restricted commands 
which may be used only at the operator's console. Three of 
the commands are concerned with the activation and deacti- 
vation of terminals. Eiefore a user can LOGON from a given 
terminal, the system must be alerted that communications 
may be coming from that terminal. The system normally Is 
alerted to this condition at IPL time. However, additional 
terminals may be brought up through use of the ATTACH 
command. A terminal may be deactivated through use of 
the DETACH command. Information on the number of active 
terminals and the nature of their activities may be displayed 
through use of the COUNT and LIST commands. The STATUS 
command wilf yield information concerning the status of an 
individual terminal. The operator may enter a message-for- 
the-day which will appear to each user at LOGON time through 
use of the DAYMSG command, or ;iend a message to a 
selected terminal via the SENDMSG command. 

Backup and Reslarf Facilities. The OASIS Data Base Is ser- 
viced by a complex set of backup routines for all update 
activities, whether they originate in the batch or online parti- 
tions. The backup trail is maintained on the OASIS logging 
tape and consists of a variety of record types which record 
all update requests at the I/O services level and also main- 
tain the status of transaction cycles and task initiations/ter- 
minations. (The logging tape also contains records used in 
producing system statistical reports.) The backup trail is re- 
corded in such a manner that restart procedures will Involve 
only those files which must be restored, although all changes 
are recorded for all files. 

Overriding all other considerations h a system like OASIS 
is the need to keep the online system m operation as much 
as possible, with few interruptions. The interruptions that oc- 
cur must be as short as possible. This need to maintain a 
stable terminal environment makes demands on the sched- 
uling of batch jobs, the design of online jobs, and on the 
nature of the backup system. The design of OASIS backup 
reflects this need, in that: 

■ The response time is affected as little as possible: relatively 
few tape records of short length are produced for backup. 

■ Every attempt is made to avoid restart \»^hen a crash occurs; 
a complex set of switches is checked prior to requesting re- 
start. 
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■ Restart time Is minimized by replaying only the records in 
those files known to require processing. 

Under OASIS, H is not possible to produce 30-second recov- 
ery procedures. The file structure makes it impractical to re- 
cord 'before* and 'after' snapshots on every modification to 
the files. The time required to write out the logging records 
would impact the response time at the terminals. As designed, 
the tape logging time is essentially absorbed within the disk 
I/O times. 

Because OASIS restart procedures require restoring parts 
of the data base and reprocessing successful updates sub- 
sequent to thai time, attention should be given to design of 
programs and procedures to reduce the number of situations 
which would necessitate restart procedures. 

Periodically, the OASIS Data Base should be dumped to 
tape and a new logging trail initiated. (No updates prior to 
that point in time will ever have to be replayed.) The dump is 
performed by executing a special OASIS batch utitity which 
selectively dumps to tape the active pages on the Data Base. 
The utility permits dumping of the entire Data Base or selec- 
tive dumping by file. Ordinarily, regularly scheduled full 
dumps shoutd be taken, then dumps of individual files taken 
prior to large batch maintenance jobs. 

The length of time to perform restart is primarily dependent 
on three things: 

■ Number of files requiring restart 

■ Volume of updates since the las* dump of the Data Base 

■ Time span since the last backup. 

The following factors are counterbalanced against the re- 
start time: 

■ The probability of a crash 

• The availability and cost of the execution time required for 
backup 

■ The consequences o\ a crash/restart at a given point in 
time. 

Under OASIS, restart Is not necessarily required each lime 
a partition crashes. Only one condition requires a mandatory 
restar^AII other restart requirements are program-induced. 

• FRIO^^^'^y restart is brought about when a partition 



aborts and at least one task was in the middle of an update 
service activity. 'Task' is defined as a batch job or one of the 
terminal programs. 'Update service activity' means that the 
task made a request to a File Services updating function and 
the I/O processing for that function was not completed. Thus, 
the cause of the crash is relatively unimportant. What is criti- 
cal is the state of the tasks that were currently in operation. If 
an update function is left incomplete, that file must be re- 
stored to insure that its indices and data records are pre- 
served. It does not matter whether that particular task caused 
the crash. 

Although only an incomplete update activity forces a re- 
start, two programming conditions may also cause a restart 
if the program is abnormally terminated: 

■ A fite maintenance program with no interna! restart facility. 

■ A file maintenance program which requires that transac- 
tions be completed in sets of multiple update functions. 

Although most programs can be designed to avoid the restart 
requirement, there will probably be circumstances when one 
of the above conditions cannot be avoided. The presence (or 
lack) o1 program-induced restart is specified to the OASIS 
backup system via certain program CALL requests. In addi- 
tion to these requests, OASIS provides a service which will 
punch a restart parameter card(s) for a batch program to en- 
able that program to avoid reprocessing when an abort 
occurs. 

When OASIS delects that a file has been invalidated, a con- 
sole message notifies the operator that restart processing 
must be done. Although the system will continue to operate 
for inquiry purposes, no further updating will be permitted 
until the restart procedures are complete. 

The OASIS restart program will list the fi!e(s) that must be 
restored and request the most recent backup tape on that 
file and the corresponding logging tape(s) from that point in 
time. Processing is then automatic: OASIS restores the active 
pages for the necessary fjte(s) and spins the logging tape to 
find and replay any successful updating records against that 
file. Additional tapes will be requested if needed and a mes- 
sage will notify the operator when the Data Base is again in- 
tact, Online OASIS and update processing may then be re- 
initiated. 
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DATA BASE SERVICES 



File Structure. Employing a hybrid file structure, the OASIS 
system provides services which allow the user to define and 
maintain an integrated Data Base. The file structure: 

■ Allows flexible deftnilion of file characteristics (e.g., index- 
. ing, security, segmentation) which can be tailored to applica- 
tion requirements. 

■ Provides for quick entry into the Data Base via indices. 
» Disengages data descriptions from programs. 

■ Provides for sequential processing based upon a particular 
key. 

■ Provides for online or batch update o1 the Data Base, in- 
cluding modification, addition, and deletion. 

• Allows for access to information in one file through its re- 
lated files. 

■ Accomplishes the above with minimum sacrifice to file com- 
pactness. 

The Data Base is physically resident on a disk storage de- 
vice which is divided into a collection of physical blocks 
called pages. There are four 1692-byte pages per track on an 
IBM 2314/^319 Disk Storage Device, seven pages per track on 
an IBM 3330 Device. (See Appendix for a pictorial description 
of t'ne Data Base.) 

The OASIS Data Base is a collection of files which may or 
may not be related. The number of files which may be in- 
cluded in any one OASIS Data Base may vary from 1 to 30,000, 
A file Is a physical collection of variable-length records, each 
of which is subdivided into a physical collection of sogmonis, 
which may contain one or more elements. The element (or 
field) is the smallest definable unit of data or information. A 
collection of elements may be defined as a group, meaning 
that they are logically (rather than physically) related. Ele- 
ments in refated files may be referenced by means of indirect 
references, A pictorial description of the 0ASI3 file structure 
is shown on the next page. 

An element is a contiguous series of bytes in one of four 
data types: character, binary, packed decimal, and zoned 
decimal. Numeric elements may specify scaling factors. Seg- 
ments may be subdivided into one or more elements. Each 
e*.«n^«^^ type Within a given file has a fixed length, although 
FR ]C^^^ differing types will usually vary, A data record 



is a collection of one or more logically related segments. 
Within any one file there can be a maximum of 254 different 
segment types. There is no relationship between segments 
with the same type number in different fifes. In general, a seg- 
ment may occur any number of times in one data record (in- 
cluding zero times). However, during file definition each seg- 
ment type may be restricted in one or both of the following 
ways: 

■ The segment may be required to appear at least once m 
every record in the file. 

■ The segment may be limited to no more than one occur- 
rence in each record In the file. 

indirect references make it possible to reference data In a 
secondary file indirectly through reference to a primary file, 
just as though the data had been contained in the file through 
which they were requested. A common usage of Indirect ref- 
erences occurs as a form of table lookup, in which an abbrevi- 
ated code is carried in the primary file and the expanded 
translation in a related secondary file so that the full field 
occurs m the Data Base only once. 

Data Base Diclionary and Data Names. Each data Hem to be 
accessed by a user must have an OASIS name by which the 
information can be specified at the user level. These names 
are specified to the system during file definition and then 
stored in the OASIS Dictionary. OASIS edit pictures are also 
specified for use in edited displays by the Generalized Ser- 
vices and by application programs as desired. The Informa- 
tion in the Dictionary may be accessed by a user program 
by means of the DESCRIBE service. 

Valid OASIS names and passwords: 

■ are from one to sixteen characters in tength, with the per- 
missible charactero being the letters A through Z, the digits 
0 through 9, and the period. 

■ must begin with a letter, 

■ must not end with a period. 

OASIS edit pictures are used to specify bow element data 
are to be edUed for display purposes. The rules for formation 
of those pictures are extremely broad and permit inclusion of 
almost any printable character. 
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The OASIS Dictionary is used by File Services as a master 
directory in rnanipufating the data within (he records of the 
Data Base according to requests from application programs 
and Generalized Services programs. Because OASIS names 
need not be unique within the Data Base, qualification with 
a particular file would often have to be performed. Since each 
data name may be as long as sixteen characters, much space 
would be required by FWe S^^rv/ces to Identify the requested 
information. Instead, a unique 4-byte compact reference is 
assigned to each element, group, and indirect reference. This 
compact reference is then used for all File Services routines. 

However, sir^ce the full names are more natural and mean- 
ingful to the user, translation services are provided to con- 
vert names to compact references (NAMETOCR service) and 
back again (CRTONAME service). This approach also makes 
it possible for the user of File Services to separate his 
logic for testing the validity of a data request from the logic 
for actually making the data request. 

Secunly Structure. Maintaining confidentiality of data in com- 
puter systems requires detailed attention to many different 
facets of mformation handling. Included are questiiDns of the 
physical location and security of computer processors, fifes, 
and terminals; handling of machine readable data in forms 
such as disk packs and magnetic tape reels; procedures 
for user offices to safeguard information in hardcopy form, 
and the measures taken in the data base syslem to provide ac- 
cess only to authorized individuals. The discussion below fo- 
cuses on the security features which are emlt?edded in OASIS 
itself; however, adequate protection of sensitive information 
will require policie^i and procedures that embrace \he whole 
range of forms ana uses of data stored in the system. 

All information stored in OASIS data (ites has associated 
with it two security codes, an access code and a modify code, 
which control the use of the information. AU users of the 
OASIS syslem will also have two security clearances, an ac- 
cess ctearance and a modify clearance, which determine the 
files and information in the files which the user is permitted 
to access and modify. (Modify clearance is required both to 
change the value of old data and to create new data.) 

Each data file in the OASIS system has its own set of secu- 
-■* -^--'os, which do not relate to those of any other file. Each 
pDlpl h:;s its own access and modify securily codes. 



Groups do not have their own security codes but are con- 
troiied by (he individual security codes for elements In the 
group. Each segment type has its own access and modify 
security codes, which default to the lowest codes which cover 
all the elements in the segment. 

For an OASIS user to either access or modify data in an 
OASIS file, he must have a security clearance for that file 
which is either equal to or greater than the security code of 
that data. The security clearance tor a given user is deter- 
mined by the password he provides during LOGON. Each 
password has associated with it the access and modify clear- 
ances for one or more files which the holder of the given 
password has been authorized to use. 

Data base security levels of three kinds are provided in the 
OASIS system: 

■ A main hierarchy 

■ 26 exclusWe fiierarchies 

■ An absolute c-^ecurity. 

The main hierarchy for each OASIS file consists of 32 se- 
curity levels, known as levels 1 through 32. There are also 26 
exclusive hierarchies, denoted as hierarchies A through Z. 
There is no significance to the Alphabetic order of the exctu< 
sive hierarchies: they are all separate, equal, and identical in 
form and operation. The final level of security is called ab- 
solute security, denoted ABS, and is greater than all other 
securities. 

Each exclusive hierarchy contains eight levels. 1 through 8; 
these are denoted AJ through A, 8, 8,1 through 8,8, and so 
forth. Within each exclusive hierarchy the levels have the ob- 
vious relationship, so that 0,5 is higher than 0,4; thus 0,8 is 
the highest level in (he 0 hierarchy, while 0,t is the lowest. 
The exclusive hierarchies have no relationship to each other, 
except that they are mutually exclusive in the sense that 
a user can access information which has a securily code' 
in the same exclusive hierarchy as his particular security 
clearance but cannot access information from any of the other 
25 exclusive hierarchies. A security code of 0,3 is neither 
higher nor lower than a code o1 K,6 because the two codes 
belong to different hierarchies. 

The main and exclusive hierarchies are related so that each 



level within each exclusive hierarchy covers a part (or all) of 
the main hierarchy. Each level in an exclusive hierarchy cov- 
ers four times as many levels in the main hierarchy as it does 
in the exclusive. For example, security F,3 covers (is greater 
than or equal to) not only its own securities F,1, F,2, and F,3 
but also securities 1 through 12 in vhe main hierarchy. How- 
ever, while each level in each exclusive hierarchy covers a 
part of the main hierarchy, no level in the main hierarchy 
covers any part of any of the exclusive hierarchies. 

If an OASIS file contains only one kind of information, only 
the main hierarchy need be applied, using as many of the 32 
levels as are needed. 

If an OASIS file contains information which has been gath- 
ered from many independent sources, the exclusive hier- 
archies may be used. Such gathering of dissimilar information 
Into one file may reduce the storage requirement and elim- 
inate the problem of updating separate records of addresses 
and other common information. 

if a file has two kinds of common information (one to be 
shared by everyone, and one to be shared only by certain 
groups of users), an overlapping of the main and exclusive 
hierarchies may be used. The truly common information may 
be placed at the bottom of the main hierarchy, say at access 
level 1 . The common information to be shared by some of the 
users may be placed in the middle of the hierarchy, say at 
level 1 7. All of the other information is placed m various exclu- 
sive hierarchies. The users who are not to be given access to 
the partially confidential informalron are given access to their 
exclusive hierarchies, but they are restricted by convention 
to the exclusive levels 1 through 4, which keeps them from 
accessing the data at main level 17. The groups of users who 
are to share all of the common information use their exclu- 
sive hierarchies; however, by convention, they are assigned 
levels 5 through 8, so that they are always given access clear- 
ance {o the common information at fevel 1 and level 17. 

File Access and Modlficallon. OASIS File Services provides 
the capability to create, maintain, and access files. Creation 
of a file requires the execution of four batch programs: 
■ Fife Definition. An updated OASIS Dictionary is created, 
w^^'^^^'^'^ntams information on the names and structures to 
^rD ir^vlth the new file. 



■ Space AllocaUon. An area within the Oata Base is allocated 
for storage of the new file and Its indices. 

■ File Build, The new file is built on disk from tape input data, 
and an intermediate tape file is produced which will be used 
in creating index tables. 

■ Index Build. The intermediate tape file is used 1o produce 
the Record Number Index and Value Index Tables required 
by the file. 

Once the four creation programs have been successfully 
completed, the user may access and update his file by 
means of the Generalized Services or through application 
programs which utilize the File Services routines. These rou- 
tines include user services to: 

■ Obtain descriptive information about the Data Base (DE- 
SCRIBE, NAMETOCR, CRTONAME, GETVAL) 

■ Access, sort, and subset fiies (ATTACH, DETACH. SELECT) 

■ Access and modify data al the record and segment levels 
(GETSEG, RPLSEG, ADDSEG. DELSEG) 

■ Access and modify data al the element level (GETDATA, 
RPLDATA) 

■ Log online transactions on tape (TAPEWRIT). 

All of the services may be called from COBOL and ALC pro- 
grams by means of a standard COBOL CALL statement. The 
requests include a return-code argument, which is set at the 
end of each request. 

There are two general methods of accessing OASIS files: 

■ Direct read from the file, either by a given element value 
search or according to a given ordering of the file by one in- 
dexed element 

■ Indirect read, via a list of record numbers which were pre- 
selected according to a set of selection criteria and/or order- 
ing specifications. 

The first method of file access is designed to be used m the 
following three situations: 

■ Random retrieval according to one specific indexed ele- 
ment value 

■ Retrieval of all the records in the file, in the order of a speci- 
fied indexed element 

■ Retrieval of all the records in the file, in the order they were 
added to the file. 



The second method of file access is used to select records 
out of a subset of records from a file, or to request records 
from a file (or fite subset) in a given order other than that of 
a single indexed element. This method of file access requires 
calling the SELECT service prior to other access functions. 
SELECT constructs a list of record numbers of all records in 
the file that meet the user-specified selection criteria, sorts 
the list if necessary, and returns a pointer by which the user 
may indicate the location of the resultant list to tho I/O rou- 
tines. SELECT is activated by an application program request 
or a QUERY or TRG specification, which may contain as many 
as 20 conditional expressions connected by OR, AND, or 
TAND* and up lo 10 sort fields. Valid operators are EQ, NE, 
GR, LS. LE, GE, and RN (range). 

In order to access data in the Data Base, the user must 
specify the file(s) containing the desired data. File Services 
can then clear the user's security before any I/O requests are 
made. This service is called ATTACH. The opposite service/ 
DETACH, removes user access from the file(s). It Is neces- 
sary to attach a file, since ail of the I/O services check to see 
if the file has been properly attached and examine the asso- 
ciated security levels before returning any data to the user or 
modifying any data In the file. 

The File Services routines include record-level, segment- 
level, and element-level functions. Four services are provided 
lo retrieve and maintain data records at the physical segment 
level: 

GETSEQ Retrieves a particular occurrence of one seg- 
ment type. 

J RPUSEG Replaces a particular occurrence of one seg- 
ment type. This service essentially overlays 
data fields on an already existing physical seg- 
ment. (Record size does not change,) 

ADDSEQ Puts a new physical segment Into a data record. 

The service fs requested in such a way that the 
new segment automatically becomes a particu- 
lar occurrence of one segment type. (The logi- 
cal record sUe will be increased.) 




,.ls a special connector to permit compafison of data within 
,1 segment occurrence. 



DELSEG Removes a particular occurrence of one seg* 
ment type from a data record, (The logical rec- 
ord size will be shortened.) 

Two services are provided to retrieve and maintain data 
records at the physical element level: 

GETDATA Retrieves data on an element, group, and Indi- 
rect reference basis. The service can retrieve 
one occurrence of one or more elements and/or 
groups, or all of the occurrences of one element. 
(GETDATA can fetch data out of a single file or 
automatically make Indirect References to other 
files.) 

RPLDATA Changes the value of a single element. 

Additional file-accessing features are available through 
special usage of the I/O services; These features are sig- 
nalled by non-standard use of certain of the parameters: 

• All occurrences of a given element maybe retrieved at once 
(special GETDATA) 

■ All occurrences of a given segment may be retrieved at 
once (special GETSEG) 

■ An entire record may be retrieved (special GETSEG) 

■ An entire record may be added to a file (special ADDSE6) 

■ An entire record ^ay be deleted (special DELSEG). 

File Design Considerations. The design of an OASIS Data Base 
involves the entire process of systems analysis. However/cer- 
tain characteristics of OASIS should be considered when 
making such designs. Because OASIS provides the capability 
for creating an Integrated data base, it is critical that the de- 
signers of the first files are cognizant of the characteristics 
of the entire data pool. Under OASIS, no file exists In a vacu- 
um; each may relate to other files and other information. Be- 
fore any file design is attempted, enough analysis should be 
pGrformed In ail areas proposed for OASIS support in order 
to determine where data interactions and overlap occur. Ah 
effective noeans of gathering this Information is the creation of 
a data element dictionary. 

Under OASIS, the manner In which a piece of data is stored 
and specified during file definition can be of great assistance 
during access and modification Sictlvities. Since the element 
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is the basic unit used by the Generalized Services, its manner 
of usage should usually be the first consideration, the space 
requirement the second. The way a user will want to 'get al' 
his data plays an important ro!e, since much of OASIS calls 
for user specification of data. Elements should be defined in 
familiar units; their names should be descriplrVe from the 
viewpoint of the users; the edit picture should be one to which 
they can relate. 

The indexing of elements is probably the most easily abused 
aspect of the OASIS file structure. It is tempting to index 
every element that is an access point into the file* However, 
aUhbugh indexing does markedly improve access speeds on 
data items, the space required for the fndex and execution 
time needed to maintain it may outweigh the worth of occa- 
sional accesses. In determining vvhether to Index an element^ 
one should consider the fact that no element need b6 Indexed, 
since file data can be accessed according to the value of any 
element, in the order of that element, regardless of if^dexlng. 
indexing simply makes the access taster. 

The actual set of indices for a given file should be based 
on the predicted access to the fife. If need be, the Indexed 
items may be changed after the file has been used for a period 
of time sufficient to evaluate the index usage. The usual types 
of elements to consider indexing are: 

■ Primary keys 

p Unique or near unique values that are accessed frequently 

■ Very common selection criteria 

■ Flag-type Information 

■ Lookup elements for Indirect references. 

The OASIS file structure permits very efficient utilization of 



file space becf^use of the optional and recurring qualifications 
on segment types. By isolating each piece of data Into Its own 
optional segment, presumably no file space would be left idle. 
However, two factors must be taken into account when con- 
sidering one-element segments: 

■ A two-byte header is appended to each segment. 
m More lime is required to access a logical group of elements 
in separate segments than when they occur In a single seg- 
ment. 

In determining the segment structures for a given file, the first 
consideration should be the need for file space economy. 
Usually, the bigger the file the more emphasis on eliminating 
'dead' space. Within the boundaries of economy, the elements 
should be placed Into logical groups, oriented more toward 
modification thah toward access. The occurrence patterns 
of the etements should also be taken Into consideration. For 
instance, recurring items should not be combJnec< with non- 
recurring ones. 

The concept of the group has been incorporated in OASIS 
primarily as a convenience; Instead of specifying a list of ele- 
ments each lime they are needed, a single group name can 
be used to produce the same results. Because groups are 
formed on a logical basis and do not affect the physical struc- 
ture of a file, they may be added, altered, and deleted as their 
use (or misuse) becomes known. 

Indirect references should be used as space-saving devices. 
They should be used sparingly^ In that their access timings 
are much slower than direct accesses. When needed, Indirect 
references save so much fife space that the reduced access- 
ing speed is counterbalanced. 



TERMINAL SERVICES 
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Terminal Communicalions. A series of subprograms has been 
developed to facilitate communicalion with the Sanders 720 
terminals from OASIS application programs. Collectively 
called Terminal Services, the subprograms are available in 
two versions: 

■ the online OASIS version 

■ a special stand-alone version, which may be accessed 
through standard DOS linkage editing and utilized by pro- 
grams in a standard DOS operating environment. 

The stand-alone version is useful primarily when first install- 
ing OASIS. The terminal equipment may be tested and pro- 
grammer familiarity with the terminal services may be ac- 
quired even before online OASIS is fully installed. 

The chief difference between the stand-alone and OASIS 
online versions is the method of polling ternriinals: the OASIS 
Exec automatically handles polling, whereas the stand-alone 
version requires the specification of a list of terminals which 
should be polled when requested by a program. The differ- 
ence in polling methods necessitates special (unctions for the 
stand-alone version. Certain standard functions of the Exec, 
however, can be utilized in order to provide additional ser- 
vices to the online environment which are not possible in the 
stand-atone version. 

• Included in Terminal Services are eleven basic functions, 
which may be divided into three groups. 

The standard functions are: 

TERASE —fill specified block with blanks (clear block) 

TGET — receive response from attached terminal (ter- 
minal read) 

TPAGE — retrieve format and send to terminal buffer 
(display page) 

TPGPUT —send specified program contents to terminal 
buffer (display program page) 

TPUT —send Information to specified block (display 
block) 

;: ./:jho.$tand-alo funotlono are: 

J .? .:f>t6j*L —put terminal on poll list 

FPL , —remove terminal from poll list 



TPOLL —search list of terminals for one which has sent 
information 

The online OASIS functions are: 
TASKNUMB —report the terminal number 
TRESTORE — redisplay format page as saved 
TSAVE —save current format page 

These eleven functions may be grouped into five basic 
types of operation dependent on their form of communication 
within a user program: 

■ Ready the device (TASKNUMB, PTOPL, TPOLL) 

■ Initialize the screen with a format (TPAGE, TPGPUT) 
» Receive communications from the user (TGET) 

■ Alter the contents of the screen (TPUT, TERASE, TSAVE, 
TRESTORE) 

■ Release the device (RTFPL). 

All of the services may be requested from application pro- 
grams through a standard calling sequence. Each is specified 
with a set of user parameters. 

Terminal Screen Formats. The formatted terminal display Is 
utilized by terminal networks to facilitate the display and re- 
trieval of file data and is the basis for the interactive nature of 
the OASIS system. The primary consideration in the design of 
such displays is tho user, the person who will have lo Interact 
with that format. 

In designing terminal screen formats, it must be remem- 
bered that the screen is usually a replacement for printed 
"forms. Initially, for many users, the replacement will seem 
..awkward, in that the printed form required only pen or pen- 
cil, or at most a typewriter. The terminal will seem strange 
and the interaction through typed actions a poor substitute 
for the better understood and more controllable printed 
forms. Because of the natural reservations, it Is Important 
that care be exercised In designing terminal display formats. 

The.^actual creation of a terminal format Involves the de- 
sign, irnplementation, and cataloging of the layout. Th^ de- 
sign of a terminal format Is very us6r-dependent and should 
consider th^ manner in which the Information will be used. 



A knowledge of the file design may be used to reduce the 
amount of reformatting between file and terminal I/O com- 
mands. The most common display formats will involve the 
following four types of blocks: 

■ Headings and constant information 

■ Error-message/actlon-message area 

■ input user-response area 

■ Outpul program-supplied areas/ 

Having established a format design, the actual formal is 
created on a terminal to insure that; 

■ the spacing can be accomplished, using the control 
characters 

• the format does not exceed the buffer positions 

■ the iayout is balanced and well-positioned when viewed 
on the live screen. 



Any adjustments may be made to the format at the terminal. 
Subsequently it is cataloged in the OASIS loader file by 
means of the FORMATPG program, vyhich Is called from on- 
line OASIS terminals. This program may also be used to 
view, copy, and modify existing terminal formats. 

Hardcopy Output. OASIS provides the capability for printing 
out the contents of the terminal buffer. The user requests this 
service by typing a backward arrow (^) anywhere on the 
screen. (The arrow itself will not be printed on the hardcopy 
device.) The type of printer (if present) may vary and Is spec- 
ified for each terminal through an installation parameter. 

Hardcopy printouts may also be requested directly from an 
applicatron network through a special set of OASIS CALL re- 
quests. 



GENERALIZED SERVICES 



QUERY. Generalized file inquiry allows the terminal user to re- 
trieve information from the Data Base by responding QUERY 
to the Command Language Processor. There are two malor 
types of query requests: descriptive queries and WHERE- 
clause queries. 

Descriptive queries allow the user to review names and 
specifications of the data to which he has access. Allowable 
responses are FILES/ file-name, group-name, and element- 
name. A descriptive query follows. 



FILE STUDENT. MASTER 



NAME 


fYPE 


LENG 


PICTURE 


V DATE. LAST. TRANS 


P 




99/99/99 


UNITS.ACCUM 


P 


2 


999 


UNITS. PASSED 


P 


2 


999 


UNtT. ACTIVITY 


C 


\ 




MEMBER. ID 


c 


10 


x-x/xx-xxxxxx 


MEMBER. TYPE 


c 


1 




MEMBER. NAME 


c 


23 




DUES. CLUB 


p 


2 


999 


OEFERREO 


p 


A 


$$$$$$9.99 


DEPT. NO 


c 


3 




DEPT.ND.l 


c 


3 




-MORE- 








MORE? (Y/N): Y 









First Page Descriptive QUERY for Student Master File 

If the query request Is FILES, the user receives a list of 
files to which he has access according to the OASIS secu- 
rity standards. If the request is a file name to which the user 
has authorized access, he receives a list of element descrip- 
tions for that file. The descriptions are composed of element 
name, type, length, and OASIS picture. If the request Is a 
group name in one of the user's files, a list of elements In the 
group is produc6d. If the request Is an element name In one 
of Jihe »jser*s files, a list of the values currenlly in the file Is 



|tC^lM$e queries alfow tho user fo sefect and view 
: In his files. Certain functions and erith- 

ign j^-fSeM^^ may be Incorporated to display modified 



data. Automatic columnar formatting is performed, and the 
user Is provided an option to view his data in rows Instead. 
Standard headings are Included and the data is edited accord- 
ing to the picture specifications in the OASIS Dictionary. 

Prior to the use of a WHERE-clause query, the user must 
specify a primary file that he intends to access. Specification 
is done by the response QFILE. file-name/ The named file Is 
then attached and remains the inquiry file until the user again 
responds with the OFILE form. 

Having specified a file, the user may then proceed with his 
requests. All WHERE-clause queries are of the form; 



(RECORDS) 



[WHERE selection-clause). 



If the "WHERE selection-Clause" option Is chosen, data will be 
selected according to the user specification. If no WHERE- 
clause Is Included, data will be selected from ail the records 
in the file. A specification of RECORDS will result In a count 
of records meeting the selection criteria. 

A (fet-term may be an element name, a group name, an 
indirect reference name, a function, or an arithmetic expres- 
sion; (Group names will be converted automatically to a list 
of element names.) A function consists of a function code 
followed by an element name. Allowable function codes are: 
SUM, COUNT, AVG, MIN; and MAX. (COUNT provides the 
total number of occurrences of a given element^ Including 
multiple occurrences in recurring segments.) An arithmetic 
expression consists of single numeric element names, func- 
tions, or literal constants separated by the single operators 
4- ~ / *. One WHERE-clause query may contain a maximum 
of twenty literal constants and/or elements, A maximum of 
five functions and five arithmetic expressions may be used 
In one query. 

QUERY output Is displayed one page at a time. Each page 
begins with a statement of the query request and element 
headings and ends with the current page-number. The user 
may then respond according to which page he wants to see 
next: none, next, previous, last, or a particular one. If he 
specifies a numher greater than the total number of pages, 
he automatically receives a display of the final page of out- 
put. He Is free to page back and forth through his output 
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BASIC. STUD JNFO WHERE MAJOR RN '0^0'/' Oii8' 


AND SEX. CODE 


EQ 'F' . 




MEMBER 10 


MEMBER. NAME 


S 


M 


MA J. 0 ESC 


LQR CLS 


DATE. LAS 




CORNELIUS, JODY ANDREA 


f 


S 


ENGLISH 


3/69 JR 


07/26/71 


0-1/67-0^3601 


HENKE. SUZETTE A^N 


F 


s 


ENGLISH 


i*/69 GRAD 


07/23/71 


0-V68-065612 


MINCHENBERG, NA^CY LEE 


F 


s 


ENGLISH 


3/69 JR 


07/26/71 


0-1/67-005373 


KYOANS, SHELLEY 


F 


s 


ENGLISH 


3/69 SR 


07/26/71 


0-1/66-0600^*3 


FERRARI , TERESA MARY 


F 


s 


HISTORY 


1/69 SR 


07/26/71 


0-1/69-05503^ 


GiLBERTi DEBORAH 


F 


s 


HISTORY 


3/69 SR 


07/22/71 


0-1/69-03^^26 


MILLS, ANNETTE M 


F 


M 


HISTORY 


3/69 JR 


07/26/7J 



PAGE 1 

PAGE? {'END' /N* ,'P' /I' ,X): N 



First Page of QUERY Showing Informallon on Female Students in Several Deparlmenls 



until he responds END. At that point, he may request a new 
query gene^:ation. EXIT terminates QUERY execution. 

Generation of data is accordtng to the OASIS security 
standards/ Blank fields will be generated in place of data 
restricted from the user. Error messages are included to 
assist the terminal user. Informational assistance is provided 
in answer to the request HELP. 

The first page of the user's query is displayed automati- 
cally. The actual generation and display of additional out- 
put pages depends entirely upon the requests of the user, 
Output Is generated in consecutive page order; however, 
only the pages prior to and including a requested page are 
generated. If the user asks for page 2 and then page 20, pages 
3 through 20 are generated even though only page 20 is dis- 
played on the screen. The pages are stored so that repeated 
requests for a given page do not require regeneration of the 
output. 

Sample queries are shown on these two pages. The first is 
an example of how the entry of a single group name can be 
used to retrieve an entire line of data. The processing of re- 
curring elements and the automatic formatting features of 
QUERY are displayed in the other example. 

Terminal Report Generator. Generalized Services also pro- 
vides a Terminal Report Generator (TRG), by which the OASIS 
user can define and generate reports using the Information 
in the Data Base. Report definition is performed online at 
the terminal. Report generation may be initiated from the 
terminal or via batch input. Reports Initiated from the termi- 
nal may be displayed page by page on the screen or may 
bo spooled to the logging tape. The user also has the option 
of generating an online proof of his report. 

Report definition is performed by responding DEFINE to 
the Command Language Processor, A series of six questions 
^^^dppear. As with all requests In the report definition phase, 
^^faiif^sponse of MORE will yield an expanded description of the 
;s.i|U^^^ Error messages are provided if Ihe user responds 

O'S^Ws^Mif^l^x (questions provide general specifications for 

llllJIflll^^ : \ : ' ; ' - ^ v;: - 

:pk'^iijhiii^()^a0^ Report name Is a 1-8 character alphanumeric 
jJ|^ifeh'^^ used to identify the given report definition. 



If the name duplicates an already existing report definition^ 
the user will be asked if he desires to replace the original re- 
port or if he wishes to select another name. 

■ Output Mode, The user has a choice of output mode. If the 
report will always be displayed on the terminal, he responds 
TERMINAL. If the report will always be printed out (except 
for proofs), the user specifies BATCH; his line definitions may 
then cover up to 132 characters. If a report may be displayed 
on the terminal or printed out, the user responds EITHER. 

■ File Name. File name Is the name of an OASIS file from 
which the data are to be extracted. 

■ Report Titie. Ihe user has a variety of options concerning 
the first line to be printed or displayed on each page of his 
report. By responding NONE he will receive no standard 
title line. A string of text enclosed In single quote marks 
will yield a heading line with that text centered on the line. 
PAGE will produce automatic page numbering. DATE will 
yield the date of actual report generation on each page of 
the report. The user may select any combination of options, 

■ Selection Criteria, The user may specify a sorting sequence 
for his report and has the capability to produce the report 
on a subset of his- {jle. Such specification is done by means 
of a SELECT WHEftE-clause. If the selection criteria for re- 
port generation will vary, the user may opt to provide selection 
criteria each time the report is produced. 

B Control Breaks. The user may select elements which he 
wants monitored so that total and summary functions may 
be performed when the value of one or more of these elements 
changes. During line definition; these control breaks are Iden- 
tified by number: the major break is 1, the next 2, and so on. 

Having completed the specifications concerning overall 
production of his report, the user is ready to define the 
format and content of the particular types of lines to appear. 
A report may be composed of three types of line: data, total, 
and text lines. Each serves a different function and Is there- 
fore defined In a unique way. 

Data lines are the detalMines of a report and are com- 
posed of Individual record data, interspersed text, and/or 
arithmetic expressions. If desired, automatic heading lines 
will be produced. Another specification will cause the head- 
ings to be produced each lime a new record Is read, appear* 
ing immediatety above the first occurrence of Ihe associated 
data tine. 
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Total lines are summary lines and may include functions 
(such as SUM and COUNT), detail data. interspersed text, 
and arithmetic expressions. Production of a total line is de- 
termined by a change In the value of one of the specified 
control breaks. The user indicates by number which break 
controls the line. Grand total lines may also be def/ned for pro- 
duction at the end of the report. Ail functions and expressions 
are computed automatically and reset after each production 
of the associated line. 

Text lines are used for a variety of reasons. They may be 
used to obtain additional report heading lines. Comments, 
notes, and informational messages may be embedded in the 
content of a report via text lines. By defining text lines which 
contain only blanks, the user can vary the spacing in his 
report. 

Each time the user specifies a data or total line, he must 
also define the information (or fields) to be contained in that 
line. Many types of field content are possible and the types 
may appear in varying combinations: 
m Data f/e/cfs. Element, group, and indirect reference names 
may be Included. At generation time the element-level secu- 
rity will be checked and, if the user is not cleared for the in- 
formation, blanks will fill the field. 

■ interspersed Text The user may embed text anywhere with- 
in his lines by enclosing the desired literal In quote marks. 
The text will appear just as typed (without the quotes) be- 
ginning at the next available position of the line. This feature 
makes possible headings to the left or right of the data fields 
and explanatory titles on total fields. 

■ Functions. Ihe iuncUons SUM. COUNT, MIN, MAX, and 
AVG may be used. When a function appears In a total line, 
the calculation Is performed from p/oduction of thai line un- 
til next production of the line, at which lime the value is reset. 
When a function appears In a data line, the value is calcu- 
lated based on a// the records to be processed, 

g Arij^mtfc Expressions. In a manner similar to that used 
::frt 00^^ numeric literals, and numeric data fields 

to;form^ expressions. ^ 

lif illHlllffi^^ ^ new Held he receives a display 

CD rr"^^ stale; i.e., he watches his line being 

tlMC^ l&lsbl^^^i'^ associated heading line, if present, 



and the previous data and total lines. Edit masks are pre- 
fixed by a dot, which will not appear on the generated report 
but is used to distinguish text from data fields. The user may 
modify the displayed lines by shortening or lengthening edit 
masks or headings and by shifting them to the left or right. 

When the user has completed definition of his report, ob- 
ject code Is produced and the complete specifications are 
saved In the OASIS Report File. The user need not, however, 
stop processing; he may choose to generate a proof of his 
report or to begin actual report generation. 

Ordinarily the user wiii want to test his report definition to 
see if it will yield the desired results. Especially for batch re- 
ports with complex selection criteria, processing of the full 
report population would be too costly and tIme-consumIng; 
The proof option permits the user to specify a simplified se- 
lection criteria and to see the report displayed on the terminal, 
produced online, even though designed for batch production. 

The user may begin report generation directly from the 
DEFINE program or by responding REPORT to the Command 
Language Processor or by calling REPORTS from the batch 
card stream. Once the mode and selection criteria have been 
established, report generation will proceed according to the 
definition specifications. 

Generation of the terminal display, terminal spooled, and 
batch reports Is basically identical except for the execution 
of the output routine. The write routine employed In the ter- 
minal display report is similar to that used In WHERE-clause 
queries: the report is produced one page at a time; paging 
is possible; a response of END causes job termination. The 
spooled report is written onto the logging tape with sorting s 
prefix and line control characters appended. The data are 
processed straight through and the job terminated when all 
lines have been produced. Batch programs are provided for 
sorting out the Individual reports and for printing them In 
batch production. The batch report is produced on a direct^ 
line-by-line basis with immediate printout; The job te/mi- 
nales with standard batch end-of-job. Card Input provides 
Information as to report name and processing options, 

A sample TRG report follows. This particular example ln< 
volved the definition of a data line and two total lines. 
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OASIS Data Base Components 

OASIS Dictionary— At the heart of File Services processing 
Is a set of entries defining each element, group, indirect refer- 
ence, file, and password in the Data Base. Information de- 
scribing the particular item follows each name and Is used 
by File Services to locate and process user data. 



Value Index Table {VIT)-^Each indexed element in the Data 
Base has an associated Value Index Table to facilitate re- 
trieval of data by element value specification. A pointer In 
the OASIS Dictionary locates the beginning of a given VIT. 
:Each VIT Is ordered by Individual element value according 
to a modified collating sequence. Each element value Is fol- 
lowed by a list of symbolic numbers of records containing 
the particular value, The VIT's are automatically updated dur- 
ing File Services maintenance routines. 

Record Number Index (RNI)— Each record is assigned a sym- 
bolic record number when added to the file. The number itself 
Mf:Mf 'S'^*''^^^^^' However, each file In the Data Base has 
vi||||4^ with it a table containing the actual physical lo- 
;i|jf|5#^^^^^^^^ to the symbolic record numbers. This 

|||§ft|||;|tt:i^^^ d af a rec o rds ^rtd V iT'sl re- 

l!li:l!?|BlSi;K f < 9 fti a I nienan ce ^ re q u I r^as one - 

ili " .KfKSIftNl ralher than modificatfons to every VIT for 

ERJC- ^ 



Data Records — All data for a given record are contiguous, in 
segment type order. All records for a given file are located 
together, with unused areas, called 'holes', interspersed to 
allow for file growth. No specific file order Is maintained; 
although pointers do exist to permit chained sequential pro- 
cessing. Pointers are also maintained within each ^hote* to 
facilitate chaining through these open areasduring file main- 
tenance. The disk space is divided into 1692-byte blocks, 
called pages; an J/0 request brings one page at a time Into 
one of a series of memory buffer areas. 

Volume Status Tables— A list of the unassigned areas on disk 
Is maintained In the Volume Status Tables for use in allocat- 
ing space during file creation, deletion/and maintenance, . 

Fife Status Tables— Information concerning the physical sta- 
tus of each file is contained in the File Status Tables and 
referenced and updated during file maintenance. Included, by 
file, are the following: last symbolic record number assigned; 
location of first disk page; location of first *hole'; chaining 
sequence of pages for the various VIT's. 

Temporary Pagos---Cerlaln of the OASIS services, including 
SELECT and the Generalized Services, use the Temporary 
Pages file for intermediate storage of data. 
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OASIS Data Retrieval Processes 



OASIS SequenliaL On the first request (la), the Status Tables 
are accessed to f/nd the address of the first RNI page for the 
appropriate file. This step is not necessary on subsequent 
requests (1 b)« From the RNI page, the physical address of the 
data page containing the desired record is obtained and the 
page can be read In from disk. Since about 400 record ad- 
dresses are contained on each RNI page, an actual read of 
an RNI page is usually required only once every 400 requests. 
A reduction In requirement for actual reads of data pages is 
also effected by the fact thai several records are often con* 
(ained on each data page of 1692 bytes. 

Given Value and Indexed Order. On all Given Value requests 
and on the first Indexed Order request (3a), the OASIS 
^ D is accessed to find the address of the VIT for the 

appropriate element, This step Is not necessary for subse- 
; quent Indexed Order requests (3b). Each VIT page contains 
5# RNTs indicating records In v/hich the specific Index 

ydlue be found. Once these RNTs are found, processing 
illllilil^^^ as In Sequential retrieval. As in 

read of 'a VIT page is: not ■ 
requests, since as many as 540 instances of 
llllffiOT b0 stored on one page. ^ 



SELECT List Order. The SELECT feature, which Is used by 
both the Generalized Services and by user written programs, 
creates a list of RNTs stored in the Temporary Pages file. Pro- 
cessing by SELECT list order {4) accesses the RNI's in the 
temporary pages in the same manner as in Sequential re- 
trieval. Approximately 550 RNI's are stored on each tempo- 
rary page. 
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TYPICAL OASIS NETWORK DESIGN 
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Terminal Display Resulting from Execution of Network Module AA 



Unlike programming In a batch environment, online pro- 
gramming under OASIS has a limit of 2048 bytes per module. 
This concept necessitates a network system design which 
can perform all the functions of a batch program while 
maintaining a rigorous modularity, GSO502 is at) online re- 
trieval and update network which is used In thfs appendfx 
to illustrate how these conditions can most effectively be 
satisfied. Throughout the execution of this network, no more 
than two levels of 2K modules occupy memory at any given 
time. In all, there are over 112 modules involved in pro- 
cessing including the root module which Is always resident 
during execution. In OASIS networks, the first module to be 
linked (o an active terminal is known as the root module, (t 
normally contains the data areas used by other modules, 
processes messages and data from the terminal, and handles 
routing to other modules. It Is sometimes difficult to find suf- 
ficient space for the data areas {i.e. COBOL Working-Storage) 
in the root module. This can be remedied to a major extent 
by making sure that Working-Storage Is redefined as much 
as possible with common information contained in the first 
portion of working storage. That not needed for common 
usage in the network can be defined as one large area, which 
subsequent modules can use through redefinition for specific 

: if\;^6^^Jf^^ networks two types of routines can be 
Udenjlfil<j emphasize common functions needed 

rielwdrk and those which are unique to' a ■ 
Networks should be wrllten In sucK'v 
S^^ "^ kinds of routines are independent of 

KCD i(^"fi&ttThe common routines are those which Involve 
ij^^vHies such as'a QETSEG (retrieve data from file) or 



TGET (accept response from terminal). Specialized routines- 
on the other hand, involve processing that Is peculiar to a 
given module or modules, such as editing a user response 
during an update. 

A network designer must be aware of what the terminal 
user Is seeing and responding to. Uncertainty by the user as 
to what Is happening should be minimized through frequent 
display of information and error messages. Through both re- 
tijeval and updating cycles of a network, It is beneficial to 
inform the user as to the result of Information he has re- 
quested or entered; I.e; If information requested cannot be 
found or if ln\faUd input data are rejected, an appropr}a\o mes- 
sage should be displayed to the user. Also, it is helpful dur- 
ing network development to display the result of any error 
conditions which result from the File Services or Terminal 
Services calls. The same area that Is to be used by the ter- 
minal operator when the network becomes operational can 
be used by programmers during the development phase. 
OASIS provides a return code area that carries the result of 
all file requests. If the request is In error It Is not necessary 
to terminate the session at the terminal; simply display the 
return codes and continue with the next response/This tech- ' 
nique will assist the programmer during the debugging phase 
of a network. 

The following material Illustrates application of the network^ 
concept to a typical function required by the terminal usefM 
the retrieval of a specified segment. Each proceduro Is called : 
a cycle, and requires loading and execution of a number of 
modules, which have boen assigned two-letter Identifiers. 5 
A cycle is (nldaled by a ''Send Block** request from the ter- 
minal for service,, and concludes with the display of new in- 
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formation on the terminal screen. The example is from the 
portion of an Alumnl/Gfft network dealing with special pro- 
gram information. After each module completes execution, 
it branches back to the root module and releases lis memory 
space for the next module required. 

(1) MODULE*AA: This module performs various Initialization 
and termination routines such as attaching and detaching 
the user files and displaying the signoff message whenever 
the end of a terminal session occurs. It begins the retrieval 
process by displaying the options available to the user, in 
the display on the previous page, the user wishes to look at 
special program information and specifies ''PROG*' plus the 
identification number of the person sought. _ 

(2) MODULE-AB: This moduJe analyzes the^ user response 
and sets up File Services parameters for member ID^ which 
is in segment Uf an invalid response option is detected/ the 
parameters are set up to display this error condition to the 
user. 

(3) MODULE^AC: This module retrieves segments from the 
file via the GETSEQ (retrieve data from file) calL The parame- 
ters forthe service are already set up when this module is 

fcbljlled^i W^^ last occurrence of a given segment is 

''teicii^^fi^ Is seL Subsequent modules test this 

:;l(4y |^^^ modlule checks the return code area 

H(tirtlhj&^f^^^ GETSEG calL If the requested ID was found 
^ d lie; the ID, name, and title from segment 1 are for- 

ERIC 



malted in the terminal display area. Once this is done, the 
correct module is selected to retrieve the segment contain- 
ing the information requested by the user via his response 
option; i.e., one of ten module names will be set at this lime. 
If the ID is not found, an error message Is issued. 

(5) MOOULE-BAr Since ''PROG" was the option chosen by 
the user, MOOiJLE-BA is entered. Because special programs 
(segment 102} can occur only once for a given member, the 
GETSEG parameters for segment 102 occurrence 1 are set 
up here. The module-name-save area is set to "BA", since 
thfs module must be reentered to check the results of the 
GETSEG cali. Module name is set to "AC" (common GET- 
SEG). If segment 102 Is found for this member, the codes 
in that segment are placed In the display area with their ap- 
propriate expansions. If segment 102 Is not found, the 
message "SPECIAL PROGRAMS NOT PRESENT FOR MEM- 
BER*' is displayed. In this example, segment 102 is not pres- 
ent for the member. 

(6) MODULE-BI: Since this particular neiwork has ten dif- 
ferent display formats. MODULE-B! analyzes the response 
the user has requested and preformats the terminal screen. 
The completed display Is shown above. 

(7} MODULE-AH: This module performs all terminal display 
functions for the retrieval phase of the GSO502 network. The 
screen format consists of from 1 to 10 blocks of Information. 
Upon exit from this module, the TGEt indicator Is turned on, 
because a response from the user will be expected. Exit from 
the module ends the cycle. 



23 



OASIS FUTURE DEVELOPMENT PLAN 



LINK PACK AREA (MVT) 

RESIDENT REENTRANT MODULE AREA (MFT-II) 



OS-OASIS MASTER TASK 
Supervisory Functions 
Data Base Functions & I/O 
Backup/Restart 



OTHER SYSTEM TASKS (if active) 



OS-OASIS ONLINE MONITOR 
Task Scheduler & Polling Routine 
Terminal Functions & I/O 
Module Loader & OASiS Buffers 
Command Language Processor 
Master Task Interface 



DYNAMIC AREA 



OS-OASIS BATCH MONITOR 
User Application Code 
tnltialixatlor^ Routines & Buffers 
Master Task Interface 



SYSTEM QUEUE SPACE 



OS-OASIS RESIDENT TYPE I SVC's 



OS NUCLEUS 




OASfS LOG 
TAPE(S) 



OASIS DATA BASE 



ONLINE 
TERMINALS 



OASIS PROGRAM 
LIBRARY 

TERMINAL SCREEN 
FORMAT LIBRARY 



OASIS CONSOLE 
(Optional) 



Processor Memory Layout for OS^OASIS 



OS*OASIS. As a result of expressions of interest fronn many 
institutions, an effort was initiated in 1972 to develop a design 
specification for a version of OASIS that would run under the 
IBM full Operating System (OS). With assistance from IBM, 
such a specification was produced, and the actual conversion 
work is under way at A non-Stanford location. It is not yet 
known when the completed and tested system will be avail- 
able. Although the design is considered !o be compatible with 
the newly announced virtual memory Operating Systems (VM, 
VS1, VS2), further development work will be needed before 
an informed judgment can be made. 

The diagram above shows a general view of the structure 
of OASIS in an OS (MFT or MVT) environment. Two differences 
that are Immediately evident are the incorporation of an 
OASIS Master Task, and elimination of the need to share the 
log tape and Data Base devices between Online OASIS and 
Batch OASIS. Muftipfe Console Support, an optional feature 
of OS. can be used to provide separation of OASIS console 
functions from OS console functions If desired. 

The concept of an OASIS Master Task allows two signifi- 
cant advantages. First, control over the Data Base and the 
fog tape is improved, since their associated physical devices 
are not shared between problem program partitions. Second. 
by c^MraUzlng OASIS service routines a saving In storage 
requirements Is achieved since these routines appear only 
once In storage Instead of once for Online OASIS and once 
y :ch OASIS/ The OS-OASiS Master Task is designed 
J G ate as an OS System Task — that is, a privileged pro- 



gram that operates as though it were a part of OS (similar to 
an OS Reader/Interpreter, Writer or Initiator). 

The OS-OASIS Online Monitor operates as a conventional 
OS job and incorporates some special facilities. The func- 
tions it provides include terminal polling, terminal I/O, user 
program loading, and scheduling of OAS^S terminal tasks. In 
addition, the Online Monitor manipulates storage and PSW 
protect keys (by use of a user v^rttten SVC) to Implement the 
OASIS storage protection feature. Another user written SVC 
(s used to notify the Master Task of a request for service from 
the Online Monitor or from a Batch Monitor, 

The OS-OASIS Batch Monitor is designed to provJde art 
interface between batch applications and the Master Task. It 
contains entry points used to resolve each service CALL that 
can be made from a batch application program. 



IBM CRT Terminals. OASIS currently allows the attachment 
of only the Sanders 720 series CRT terminals. The OASIS 
Generalized Services and Terminal Services make use of a 
number of hardware features of this termlna) that are not 
available In other vendors' equipment. Advancements in termi- 
nal capability since the OASIS design was frozen, particularly 
the IBM 3270 series CRT's, have made It desirable to expand 
the range of terminals that may be used/The OASIS develop- 
ment team at Stanford is currently destgning support for the 
IBM terminals and expects to complete this work by the end 
of 1973. 
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OASIS COMMANDS AND RESERVED WORI 
CLP Commands 
ATTACH 
BREAK 
CLEAR 
CLOCK 
CONTINUE 

CONT 
COUNT 
DAYMSG 
DEFINE 
DETACH 
DUMP CORE 
EMO FOASIS 



EXECUTE 

EXEC 
HOLD 
LIST 
LOAD 
LOGOFF 
LOGON 
MSG 
MSGR 
NEWVOL 
NOHOLO 
PATCH CORE 



PATCH GPR 
PATCH lA 
QUERY 
REPORT 
RESET 
SENDMSG 
SHOW CORE 
SHOW GPR 
SHOW MAP 
STATUS 
TEST 
TRACE 



File Servtcos Commands 

ADDSEG DETACH 
ATTACH FREEALL 
CRTONAMG FREELIST 
DELSEG GETDATA 
DESCRIBE GETSEG 
GETVAL 

Terminal Services Commands 
PTOPL TGET 
RTFPL TPAGE 
TASKNUMB TPGPUT 
TERASE 



NAMETOCR 

RPLDATA 

RPLSEG 

SELECT 

TAPEWRIT 



TPOLL 
TPUT 

TRESTORE 
TSAVE 



OASIS Reserved Words* 


A 


GR 


ALL 


HELP 


AND 


IGNORE 


AVG 


LE 


COLUM 


LS 


COLUMNAR 


MAX 


COUNT 


MIN 


D 


MORE 


EQ 


N 


FILES 


NE 


GE 


NONE 




NULL 



OR 

ORDERED 

RECORD 

RECORDS 

RN 

SUM 

TANO 

VERT 

VERTICAL 

WHERE 

Y 



' Not to be used as data names. 



